IBIS Macromodel Task Group

Meeting date: 09 May 2023

Members (asterisk for those attending):
Achronix Semiconductor:       Hansel Dsilva
Amazon:                       John Yan
ANSYS:                      * Curtis Clark
                            * Wei-hsing Huang
Aurora Systems:               Dian Yang
Cadence Design Systems:     * Ambrish Varma
                              Jared James
Google:                       Hanfeng Wang
                              GaWon Kim
Intel:                        Michael Mirmak
                            * Kinger Cai
                              Chi-te Chen
                            * Liwei Zhao
Keysight Technologies:        Fangyi Rao
                              Majid Ahadi Dolatsara
                              Stephen Slater
                            * Ming Yan
                              Rui Yang
Marvell:                      Steve Parker
Mathworks (SiSoft):         * Walter Katz
                              Graham Kus
Micron Technology:            Justin Butterfield
Missouri S&T:                 Chulsoon Hwang
                              Yifan Ding
                              Zhiping Yang
Rivos:                        Yansheng Wang
SAE ITC:                      Michael McNair
Siemens EDA (Mentor):       * Arpad Muranyi
                              Randy Wolff
Teraspeed Labs:             * Bob Ross
Zuken USA:                    Lance Wang

The meeting was led by Arpad Muranyi.  Curtis Clark took the minutes.

--------------------------------------------------------------------------------
Opens:

- None.

-------------
Review of ARs:

Arpad: Prepare a presentation and statement of the issue for the AMI_GetWave
       block size with continually adapting models topic.
       - In progress.  See discussion below.

--------------------------
Call for patent disclosure:

- None.

-------------------------
Review of Meeting Minutes:

Arpad asked for any comments or corrections to the minutes of the May 2nd
meeting.  Ambrish moved to approve the minutes.  Kinger seconded the motion.
There were no objections.

--------------
New Discussion:

How to handle the PSIJ Sensitivity BIRD draft and SPIM (BIRD223):
Arpad recapped the previous week's discussion.  He noted that Walter had shared
a presentation on where these proposals would fit into the overall scheme of
IBIS, and Kinger had reviewed some slides showing various OEM and EDA
organizations who supported SPIM.

Walter said having SPIM as a document within the purview of the IBIS Open Forum
would be great.  However, he reiterated that he thought it would be best if SPIM
were a stand-alone document and not part of the IBIS specification itself.  He
suggested that a new IBIS keyword in the .ibs file itself could be used to link
to a SPIM model file.

Arpad said that IBIS is generally a modeling language/specification, and it
typically does not get involved in prescribing flows and telling EDA tools what
to do with the models.  He said he could see SPIM describing what data goes into
a model, but he would prefer that it avoid getting into descriptions of flows.

Bob said that he understood that SPIM is quite different from what is currently
in the IBIS specification, but he favored putting SPIM into its own chapter in
IBIS itself.  He listed several reasons:
  - Most infrastructure and parser support would be there to apply to SPIM and
    a new .spim file.
  - If SPIM referenced a Touchstone file, the ibischk parser could at least
    check that its terminals were correctly defined.
  - If it were a separate specification there would be lots of duplication in
    parser code.  So, even though it would mean a fairly large change to
    ibischk, it would be preferable to dealing with an entirely separate SPIM
    document.
Bob said that it would be nice to hear from some of the vendors that had worked
with Kinger and supported SPIM.

Arpad and Kinger both recalled that Dian had stated a preference for including
SPIM in IBIS itself.  Kinger said Dian's reasoning was that the PDN nets should
be handled just as the signal nets are currently handled.

Ambrish said others in his organization had worked with Kinger.  He said that he
supported Bob's comments about reusing existing infrastructure.  He also noted
that the AMI sections of IBIS, for example, describe simulation flows already.
Arpad agreed that the AMI flows are one example of a case in which IBIS defines
flows.

Kinger shared one slide showing a VRM feeding a PDN connected to an I/O buffer
driving a channel to an Rx.  He said that traditionally IBIS only dealt with
the last stage (the Tx output buffer in his slide).  Later IBIS extended beyond
the I/O buffer and added RLC packaging, and it then introduced S-parameters and
coupled RLC models.  Now, SPIM wants to extend IBIS to contain a real PDN model
to power the buffer.  He said they want to treat the PDN as part of the overall
system that affects the I/O output.  It's a step on the way to having SI and PI
support in the same specification and toward convergence of SI/PI.

Arpad said that IBIS currently has decent capability for power-aware modeling,
but it is limited to the buffers in the simulation.  What is missing is the
information on the other sources of noise on the supply rails that feed the
power-aware IBIS buffer models.  He said SPIM is valuable because it can plug
that hole and give us more complete power information.  Since SPIM is tightly
associated with the buffer models we are simulating, he said he was thinking
that it might be useful to have SPIM as part of IBIS itself.

Walter said he agreed that the SPIM model is part of a [Component] in an .ibs
file, just as a Touchstone file is part of an IBIS Interconnect Model, but we
don't put the Touchstone specification itself inside the IBIS specification.
He noted that timing models are also integral parts of modeling a [Component],
but we don't have them in IBIS.

Arpad asked whether SPIM is a modeling language of its own.  Is it a different
language altogether than IBIS, or is it really some new keywords for a new
topic.  He said that he thought SPIM was more similar to IBIS itself than
Touchstone was.  Bob agreed that SPIM syntax is similar to existing IBIS syntax.
So, he thought it could be included as a chapter in IBIS.

Ambrish agreed with Arpad and Bob.  However, he noted that AMI is not a separate
specification, we merely have an IBIS [Model] that includes an [Algorithmic
Model] keyword.  Since AMI allows us to include things like executable models
(.dlls, .sos), we've already established a precedent for including widely
varying things in IBIS.  So, why can't we fold SPIM into IBIS if we want to,
even if its syntax were very different?

Walter suggested that we probably need some sort of vote to pick a direction.
The group agreed to hold a straw poll at the next meeting to indicate a
preference for including SPIM in IBIS (as is the case for BIRD223) or making
SPIM a stand-alone specification.  Arpad took an AR to send an email announcing
the upcoming straw poll in ATM and noting that a vote will likely take place in
the IBIS Open Forum meeting at some point.

AMI_GetWave block size with continually adapting models:
Arpad said his initial motivation for discussing this topic was a presentation
by Fangyi at the February DesignCon IBIS Summit.  The presentation discussed an
AMI Rx model that was continuously adapting throughout the simulation.  The
model's only chance to report adaptation results to the tool would be when it
returned values following each call to AMI_GetWave.  Since the AMI_GetWave
function has a parameter for specifying the size of the block of data
(wave_size), the value of which is set by the EDA tool, there could be an
interaction between the block size chosen by the tool and the time constant of
any adaptation.

Arpad shared a work-in-progress presentation on the topic.

Slide 1:
This showed slide 15 from Fangyi's February 2023 DesignCon presentation.  The
Rx slicer's threshold and offset values could vary from AMI_GetWave call to 
AMI_GetWave call due to adaptation.  Arpad noted that there are PAM4 and more
general PAMn AMI Reserved Parameters that can return voltage thresholds and
timing offsets from the model at each AMI_GetWave call.

Slide 2:
This showed the IBIS 7.2 AMI_GetWave definition and the wave_size description.
Arpad noted that the EDA tool chooses the wave_size, i.e., the size of each
block of data passed to AMI_GetWave.

Slide 3:  Three possible scenarios:
1.  AMI_GetWave takes more than one block to adapt.  The model can hopefully
    carry data across multiple blocks.
2.  The block size and the adaptation time constant line up nicely.  Everything
    is fine.
3.  The adaptation is much quicker than the block size.  Theoretically, the tool
    could be missing many updates within a given block, since the results can
    only be reported once per block.
    
Arpad said that in a worst-case example of scenario 3, the tool might end up
with a closed eye because it was using incorrect threshold values for portions
of the large data blocks.

Walter addressed the 3 scenarios.  For scenario 1, he said that if the model
works differently for different block sizes, then it's a bug in the model.  For
scenario 2, he agreed that everything is fine already.  For scenario 3, he said
he thought there were 2 possible solutions:
1.  Tell the user not to make the block size larger than XXX bits, or adaptation
    won't work.  This could be provided as documentation with the model.
2.  Or, is this just a problem with waiting out the initial convergence?  The
    Ignore_bits AMI Reserved Parameter can be used to cover this case.  After
    some initial convergence period, it's probably going to be stable and you
    won't have a block size related problem.  Just make Ignore_bits large enough
    to cover the initial convergence period.
    
Walter said he didn't see any other mechanism for scenario 3.  AMI_GetWave
should converge to steady state values after Ignore_bits.  Alternatively, if
something like ISI or data dependent effects can still lead to large shifts in
thresholds or offsets after Ignore_bits, then the model maker just has to tell
the user to use a smaller block size.

Arpad said this issue was analogous to issues with samples per bit
(sample_interval).  The specification says AMI models should work with any
sample_interval, but in practice some models require a power of 2 for samples
per bit.  The user's guide may tell the user to use 16, 32, 64, etc., samples
per bit, for example, but he said he had run into issues with improper settings
of sample_interval in the past.  He said he wished we had an AMI Reserved
Parameter that could provide that information to the EDA tool, too.  Walter said
the model can use the msg parameter to return an error message string if it has
a problem to report.

Ambrish said that we don't need to change the specification just because some
users aren't reading their models' documentation.  He agreed with Walter's
suggestion that Ignore_bits should be sufficient to cover this issue, as the
values should settle over time if the model converges properly.

Walter asked, what might cause it to vary over the longer term after initially
settling?  Arpad said a bit pattern with non-zero DC component could move
the thresholds around within a certain range even after Ignore_bits.  Walter
asked what could cause that.  He said he thought it would be hard for an
LTI Tx model to provide DC drift.  Arpad said imbalanced '1' and '0' bits could
do that, but he'd have to think about the LTI part of the question

Arpad asked whether there was any interest in pursuing this topic.  He asked
whether he should continue developing his slides on the topic.  Curtis noted
that the BCI_Message_Interval_UI AMI Reserved Parameter provides information, in
the back-channel communication context, analogous to what Arpad was describing.
Walter and Ambrish said they thought Ignore_bits was probably sufficient for any
real world modeling scenarios.  Ambrish suggested the topic could be tabled for
now and reconsidered if we see users and model makers running into trouble.

- Kinger: Motion to adjourn.
- Curtis: Second.
- Arpad: Thank you all for joining.

New ARs:

Arpad:  Send an email announcing the straw poll ATM vote on whether to include
        SPIM in the IBIS specification itself or make it a stand-alone
        specification.

-------------
Next meeting: 16 May 2023 12:00pm PT
-------------

IBIS Interconnect SPICE Wish List:

1) Simulator directives
